What the bug is

This PR makes a series of parallel changes to two example apps that are clearly meant to mirror each other: examples/demo/src/hooks/useOneSignal.ts and examples/demo_pods/src/hooks/useOneSignal.ts. In both files the PR rewrites pushSubHandler byte-identically (the same fmtToken helper, the same template literal, the same destructuring of previous/current) and adds the same 'Uncomment if you want so you have time to see logs while trying to open safari web inspector' comment block at the top of load(). However, the demo file also gets a new console.log(\Permission changed: ${granted}`)line insidepermissionHandler`, while demo_pods does not.

The specific code path

In examples/demo/src/hooks/useOneSignal.ts (around the changed lines), the handler now reads:

const permissionHandler = (granted: boolean) => {
  console.log(`Permission changed: ${granted}`);
  setHasNotificationPermission(granted);
};

In examples/demo_pods/src/hooks/useOneSignal.ts at lines 213-215, the same handler instead reads:

const permissionHandler = (granted: boolean) => {
  setHasNotificationPermission(granted);
};

Both handlers are wired up via OneSignal.Notifications.addEventListener('permissionChange', permissionHandler) later in the same effect, and the surrounding handlers (pushSubHandler, userChangeHandler, handleNotificationClick, handleForegroundWillDisplay, the IAM listeners) all have matching console.log calls in both files.

Why existing code doesn't prevent it

These are example apps, not part of the published SDK. There is no shared module between the two demos and no test that asserts they stay in sync, so a forgotten line in one of them passes lint, type-check, and CI.

Impact

Negligible at runtime — the missing log line only changes what the developer sees in the JS console while exercising demo_pods. It does not affect plugin behavior, packaged output, or end users in any way. This is purely a consistency/debugging-ergonomics nit.

Step-by-step proof

1. Open examples/demo/src/hooks/useOneSignal.ts and find permissionHandler — it has two statements: a console.log and a state setter.
2. Open examples/demo_pods/src/hooks/useOneSignal.ts and find permissionHandler at lines 213-215 — it has only the state setter.
3. Compare the surrounding handlers in both files: pushSubHandler is byte-identical, including the exact Push subscription changed: id=… log message. userChangeHandler is byte-identical, including the User changed: onesignalId=… log. The IAM willDisplay/didDisplay/willDismiss/didDismiss/click handlers are all byte-identical with their console.log calls. Even the load() comment about Safari web inspector is byte-identical.
4. Conclusion: the two files are intentionally kept in lockstep in this PR, but permissionHandler is the single divergence — a missed parallel edit.

How to fix

Add the same line to examples/demo_pods/src/hooks/useOneSignal.ts so its permissionHandler reads:

const permissionHandler = (granted: boolean) => {
  console.log(`Permission changed: ${granted}`);
  setHasNotificationPermission(granted);
};

One-line fix, no risk.